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Abstract 

To  date,  the  tabular-based  SCR  (Software  Cost  Re¬ 
duction)  method  has  been  applied  mostly  to  the  devel¬ 
opment  of  embedded  control  systems.  This  paper  de¬ 
scribes  the  successful  application  of  the  SCR  method , 
including  the  SCR*  toolset,  to  a  different  class  of  sys¬ 
tem,  a  COMSEC  (Communications  Security)  device 
called  CD  that  must  correctly  manage  encrypted  com¬ 
munications.  The  paper  summarizes  how  the  tools  in 
SCR*  were  used  to  validate  and  to  debug  the  SCR  spec¬ 
ification  and  to  demonstrate  that  the  specification  sat¬ 
isfies  a  set  of  critical  security  properties.  The  devel¬ 
opment  of  the  CD  specification  involved  many  tools  in 
SCR*:  a  specification  editor,  a  consistency  checker,  a 
simulator,  the  TAME  interface  to  the  theorem  prover 
PVS,  and  various  other  analysis  tools.  Our  experience 
provides  evidence  that  use  of  the  SCR*  toolset  to  de¬ 
velop  high-quality  requirements  specifications  of  moder¬ 
ately  complex  COMSEC  systems  is  both  practical  and 
low-cost. 

1  Introduction 

COMSEC  (Communications  Security)  devices,  de¬ 
vices  which  manage  encrypted  communications,  are 
vital  to  the  correct  operation  of  U.S.  military  sys¬ 
tems.  CD,  the  COMSEC  device  of  interest  in  this 
paper,  is  designed  to  provide  cryptographic  processing 
for  a  U.S.  Navy  radio  receiver.  In  addition  to  generat¬ 
ing  keystreams  compatible  with  another  cryptographic 
device  and  supporting  multiple  channels  and  multiple 
cryptographic  algorithms,  CD  downloads  associated  al¬ 
gorithms  and  keys  into  working  storage,  assigns  them 
to  designated  communication  channels,  maintains  the 
association  between  an  algorithm  and  its  keys,  and 
clears  algorithms  and  keys  from  memory.  CD,  based 
on  a  technology  called  PEIP  (Programmable,  Embed¬ 
dable  INFOSEC  Product)  for  implementing  COMSEC 
devices  in  software  as  well  as  hardware,  presents  a 
new  challenge  in  the  development  of  COMSEC  devices. 
While  a  solid  base  of  experience  exists  for  implement¬ 
ing  trustworthy  COMSEC  devices  in  hardware,  imple- 
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menting  COMSEC  devices  in  software  is  rare. 

During  the  last  decade,  numerous  formal  methods, 
many  with  automated  support,  have  been  proposed  for 
developing  high  assurance  software  systems.  Because 
studies  (e.g.,  [6])  show  that  errors,  such  as  security 
property  violations,  that  are  introduced  early  in  system 
development  are  both  the  most  common  and  the  most 
expensive  to  fix,  the  goal  of  many  formal  methods  is 
to  discover  and  eliminate  flaws  during  the  early  stages 
of  system  development.  While  mechanically  supported 
formal  methods  hold  great  promise  for  identifying  er¬ 
rors  early,  the  exceptional  user  expertise  and  effort  usu¬ 
ally  required  to  apply  them  present  a  major  barrier  to 
their  use  in  the  development  of  practical  systems. 

The  SCR  (Software  Cost  Reduction)  method  [15, 
11]  is  a  formal  method  which  offers  a  user-friendly  tab¬ 
ular  notation  for  specifying  system  requirements,  and 
a  set  of  tools  called  SCR*  for  detecting,  often  auto¬ 
matically,  flaws  in  the  requirements  specification.  Al¬ 
though  originally  designed  to  specify  the  requirements 
of  safety-critical  control  systems,  SCR  can  also  be  used 
to  specify  the  required  behavior  of  other  systems,  such 
as  COMSEC  systems.  To  make  SCR*  useful  to  prac¬ 
titioners,  the  tools  are  designed  to  be  as  automatic  as 
possible  and  to  complement  and  support  one  another. 
Included  among  the  tools  in  SCR*  are  an  automated 
consistency  checker,  a  simulator,  and  various  verifica¬ 
tion  tools. 

To  provide  a  high  degree  of  assurance  in  the  correct¬ 
ness  of  CD’s  specification,  we  have  applied  the  SCR 
method,  including  the  SCR*  tools  [12,  13,  11].  Our 
results  suggest  that  applying  the  SCR  method  in  the 
development  of  COMSEC  devices  of  moderate  size  and 
complexity  is  practical,  effective,  and  low-cost.  In  ap¬ 
proximately  one  person-month,  we  were  able  to  repre¬ 
sent  a  significant  subset  of  a  prose  requirements  doc¬ 
ument  for  CD  in  the  the  SCR  notation  and  to  estab¬ 
lish  that  the  SCR  specification  satisfies  a  set  of  se¬ 
curity  properties.  The  product  of  this  effort  is  a  high- 
quality  requirements  specification  in  whose  correctness 
we  have  a  high  degree  of  confidence.  This  requirements 
specification  can  guide  both  the  development  of  the 
source  code  and  the  development  of  test  sets  for  eval- 
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uating  the  conformance  of  the  source  code  with  the 
system  requirements. 

The  paper  is  organized  as  follows.  It  first  introduces 
the  SCR  method  and  the  SCR*  toolset  in  Section  2, 
and  then  describes  in  Section  3  how  the  tools  were  ap¬ 
plied  to  CD.  Section  4  discusses  the  results  of  apply¬ 
ing  SCR*  to  the  CD  specification.  Finally,  section  5 
discusses  related  work,  and  Section  6  presents  our  con¬ 
clusions. 

2  The  SCR  Method  and  Tools 

The  SCR  method  is  a  formal  method  designed  to 
specify  and  analyze  the  requirements  of  safety-critical 
control  systems.  Since  its  introduction  in  1978,  the 
SCR  requirements  method  has  been  applied  success¬ 
fully  to  a  wide  range  of  critical  systems,  including 
avionics  systems,  space  systems,  telephone  networks, 
and  control  systems  for  nuclear  power  plants.  See, 
e.g.,  [15,  23,  8',  7,  22,  19]. 

An  SCR  requirements  specification  describes  both 
the  system  environment,  which  is  nondeterministic, 
and  the  required  system  behavior,  which  is  usually 
deterministic  [12,  14].  Quantities  in  the  environment 
that  the  system  monitors  and  controls  are  represented 
by  monitored  and  controlled  variables.  SCR  specifi¬ 
cations  also  use  two  types  of  auxiliary  variables:  mode 
classes  (whose  values  are  called  modes )  and  terms ,  both 
of  which  often  capture  historical  information.  In  the 
SCR  model,  the  system  environment  nondeterministi- 
cally  produces  a  sequence  of  input  events,  where  an  in¬ 
put  event  is  a  change  in  some  monitored  quantity.  The 
system  is  represented  as  a  state  machine  (i.e.,  automa¬ 
ton)  whose  current  state  is  determined  by  the  values 
of  the  state  variables,  where  a  state  variable  is  either 
a  monitored  or  controlled  variable,  a  mode  class,  or 
a  term.  Executions  of  the  system  begin  in  some  ini¬ 
tial  state,  after  which  the  system  responds  to  each  in¬ 
put  event  in  turn  by  changing  state  and  by  producing 
zero  or  more  output  events,  where  an  output  event  is  a 
change  in  a  controlled  quantity.  The  system  behavior 
is  assumed  to  be  synchronous:  the  system  completely 
processes  one  input  event  before  the  next  input  event 
is  processed. 

An  SCR  specification  defines  the  transitions  of  a 
system  using  of  a  set  of  tables.  Each  table  describes 
the  value  of  a  given  state  variable  in  the  new  state. 
Each  dependent  variable,  i.e.,  each  controlled  variable, 
term,  and  mode  class,  has  a  corresponding  table.  Two 
constructs  used  in  the  tables  are  conditions  and  events. 
A  condition  is  a  predicate  on  system  states.  An  event 
occurs  when  the  value  of  any  variable  changes.  The 
notation  “@T(c)  WHEN  d”  denotes  a  conditioned  event 
defined  as 

@T(c)  WHEN  d  =f  —iC  A  c'  A  d, 


where  the  unprimed  conditions  c  and  d  are  evaluated 
in  the  “old”  state,  and  the  primed  condition  d  is  eval¬ 
uated  in  the  “new”  state.  Informally,  this  denotes  the 
event  “predicate  c  becomes  true  in  the  new  state  when 
predicate  d  holds  in  the  old  state”.  The  table  for  a 
mode  class  is  a  mode  transition  table ,  which  maps  a 
source  mode  and  an  event  to  a  destination  mode.  The 
table  for  any  term  or  controlled  variable  is  either  an 
event  table ,  which  maps  conditioned  events  to  values 
of  the  variable  in  the  next  state,  or  a  condition  table, 
which  maps  conditions  on  the  next  state  to  values  of 
the  variable  in  the  next  state. 

In  addition  to  tables,  an  SCR  specification  contains 
dictionaries  of  types,  variable  declarations,  constant 
declarations,  environmental  assumptions,  and  specifi¬ 
cation  assertions.  The  specification  assertion  dictio¬ 
nary  records  required  system  properties,  e.g.,  security 
properties.  Our  experience  with  practical  systems  is 
that  most  system  properties  can  be  represented  as  ei¬ 
ther  state  invariants  or  transition  invariants,  where  a 
state  invariant  is  a  property  that  holds  in  every  reach¬ 
able  state  and  a  transition  invariant  is  a  property  that 
holds  in  every  reachable  prestate/poststate  pair  (i.e., 
reachable  transition) . 

The  SCR*  toolset  [12,  13,  11]  is  a  set  of  software 
tools  developed  by  NRL  to  provide  mechanized  sup¬ 
port  for  the  SCR  method.  The  tools  include  a  specifi¬ 
cation  editor  for  creating  and  modifying  both  an  opera¬ 
tional  requirements  specification  (i.e.,  a  state-machine 
representation  of  the  required  behavior)  and  a  set  of 
properties,  such  as  safety  and  security  properties;  a 
dependency  graph  browser  to  display  the  dependencies 
among  the  variables  in  the  specification;  an  automated 
consistency  checker  to  expose  missing  cases,  unwanted 
nondeterminism,  and  other  application-independent 
errors  [12];  a  simulator  to  allow  users  to  validate  the 
specification;  an  interface  to  the  model  checker  Spin 
[16]  to  detect  violations  of  critical  application  prop¬ 
erties;  and  an  invariant  generator  [18]  that  computes 
state  invariants  from  an  SCR  specification.  To  provide 
formal  underpinnings  for  the  tools  and  for  the  anal¬ 
ysis  techniques  the  tools  implement,  a  formal  model 
defines  the  semantics  of  SCR  requirements  specifica¬ 
tions  [14,  12], 

Several  additional  tools  have  been  recently  inte¬ 
grated  with  SCR*  by  automatically  translating  the 
internal  representation  of  an  SCR  specification  into 
the  input  languages  of  the  tools.  These  tools  in¬ 
clude  TAME  (Timed  Automata  Modeling  Environ¬ 
ment)  [1,  2],  an  interface  to  the  theorem  prover  PVS 
[25]  for  proving  properties  of  automata  models,  a  va¬ 
lidity  checker  [4]  which  uses  an  integrated  set  of  deci¬ 
sion  procedures  to  automatically  check  whether  a  given 
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property  is  a  state  or  transition  invariant  of  an  SCR 
specification,  and  a  test  set  generator  [9]  that  automat¬ 
ically  generates  test  sets  from  an  SCR  specification. 

3  Applying  SCR*  to  CD 

This  section  describes  the  translation  of  a  subset  of 
the  prose  specification  provided  by  the  CD  developers 
into  an  SCR  specification  and  the  results  of  applying 
the  SCR*  tools  to  the  SCR  specification.  The  tools  and 
analysis  techniques  that  were  applied  include  the  con¬ 
sistency  checker,  simulator,  invariant  generator,  Spin, 
TAME,  and  the  validity  checker.  This  section  also  de¬ 
scribes  our  plan  to  use  the  SCR*  testing  tool  to  auto¬ 
matically  construct  test  sets  from  the  SCR  specifica¬ 
tion  of  CD. 

3.1  From  Prose  to  SCR  Requirements 

To  develop  the  SCR  specification,  we  studied  the 
CD  Systems  Requirement  Document  (SRD)  provided 
by  the  CD  project  manager,  focusing  on  the  constraints 
it  imposed  on  the  required  system  behavior  and  repre¬ 
senting  those  constraints  using  SCR  constructs.  The 
CD  SRD,  a  traditional  2167A-style  document,  was  suf¬ 
ficiently  precise  and  complete  about  key  and  algorithm 
management,  modes  of  operation,  and  security  require¬ 
ments  relating  to  power,  tampering,  and  zeroizing  for 
us  to  capture  the  required  behavior  in  the  SCR  speci¬ 
fication  of  CD.  We  obtained  security  properties  by  ex¬ 
amining  the  SCR  specification  and  surmising  the  goals 
of  the  required  behavior  and  by  interpreting  descrip¬ 
tions  of  functions  in  the  CD  SRD  as  security  require¬ 
ments.  The  CD  project  manager  has  reviewed  the 
set  of  security  properties  that  we  formulated  and  con¬ 
firmed  that,  except  for  one,  they  are  reasonable  se¬ 
curity  properties  of  CD.  The  exception,  according  to 
the  project  manager,  was  a  property  whose  hypothesis 
(backup  power  is  over  voltage),  would  never  be  satis¬ 
fied. 

Our  SCR  specification  describes  the  part  of  CD’s  be¬ 
havior  (as  described  in  the  SRD)  that  is  consistent  with 
the  SCR  model  of  black-box  requirements.  In  SCR, 
the  CD  behavior  is  described  in  terms  of  inputs  (the 
status  of  primary  and  backup  power,  data  provided  by 
the  host,  and  positions  of  switches),  outputs  (indicator 
lights  and  status  messages),  and  modes.  In  addition, 
our  specification  describes  some  memory  management 
behavior  that  goes  beyond  SCR’s  usual  modeling  of 
black-box  requirements.  Usually,  in  SCR,  memory  is 
considered  to  be  internal  to  the  black  box,  and  thus 
invisible  from  the  outside,  but  we  treat  it  as  externally 
visible  by  defining  controlled  variables  that  represent 
the  memory  locations  in  which  the  CD  software  can 
store  algorithms  and  keys.  This  memory  management 
behavior  models  the  rules  in  the  CD  SRD  for  loading 
algorithms  and  keys,  associating  them  with  channels, 


and  clearing  them  from  memory.  There  is  (intention¬ 
ally)  not  enough  information  in  the  CD  SRD  to  specify 
the  rules  for  cryptographic  synchronization  and  gener¬ 
ating  keystreams.  As  a  result,  our  SCR  specification 
omits  some  required  behavior  that  would  be  relevant 
and  useful  to  reason  about. 

The  CD  SRD  assumes  that  an  unlimited  number  of 
algorithms  and  keys  can  be  distributed  among  an  un¬ 
specified  number  of  storage  locations  and  an  unspec¬ 
ified  number  of  channels.  In  the  SCR  specification, 
we  assume  that  there  are  two  key  banks,  each  with 
two  key  storage  locations;  at  most  1,000  different  al¬ 
gorithms  and  1,000  different  keys;  and  two  channels. 
The  SCR  CD  specification  has  one  more  mode  than 
described  in  the  CD  SRD:  we  add  an  Off  mode  so  that 
the  system  is  always  in  exactly  one  mode. 


Figure  1 .  Full  dependency  graph  for  SCR  CD. 


Our  SCR  specification  contains  39  variables — 17 
monitored  variables,  one  mode  class,  two  terms,  and 
19  controlled  variables.  Figure  1  shows  the  variable 
dependency  graph  for  the  complete  SCR  specification 
of  CD.  Variables  are  represented  as  boxes,  and  an  ar¬ 
row  from  one  variable  to  a  second  variable  indicates 
that  the  value  of  the  first  variable  in  the  new  state 
depends  on  the  value  of  the  second  variable  in  either 
the  current  state  or  the  new  state.  The  heavy  lines 
are  backarrows;  the  number  of  backarrows  reflects  the 
complexity  of  the  dependencies  among  the  variables, 
which  is  also  reflected  in  the  complexities  of  the  tables. 
Although  this  graph  has  cycles,  the  SCR*  consistency 
checker  was  used  to  assure  that  there  were  no  circu¬ 
lar  dependencies  among  the  “new-state”  variables  (see 
Section  3.2). 

Most  of  the  effort  spent  in  building  the  SCR  specifi¬ 
cation  of  CD  took  place  as  a  background  activity  over 
a  nine-month  period.  The  initial  build  of  the  specifica- 
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tion  required  approximately  one  person-week.  About 
one  additional  person-week  was  needed  to  refine  and 
complete  the  specification,  with  frequent  use  of  the 
consistency  checker  (see  Section  3.2). 

3.2  Applying  the  Consistency  Checker 

The  consistency  checker  uses  static  analysis  tech¬ 
niques  to  expose  syntax  and  type  errors,  variable  name 
discrepancies,  unwanted  nondeterminism  (called  dis¬ 
jointness  errors ),  missing  cases  (called  coverage  er¬ 
rors ),  and  circular  definitions  (i.e. ,  cycles  in  the  de¬ 
pendencies  among  new-state  variables).  The  checks 
are  fully  automatic  and  thus  require  no  user  input 
or  guidance.  When  an  error  is  detected,  the  consis¬ 
tency  checker  facilitates  error  correction  by  providing 
detailed  feedback.  For  some  types  of  errors  (e.g.,  dis¬ 
jointness  and  coverage  errors),  the  checker,  in  addition 
to  describing  the  error,  will  highlight  where  in  the  spec¬ 
ification  the  error  occurs,  and  display  a  transition  or 
state  that  demonstrates  the  error. 

The  consistency  checker  may  be  used  at  any  stage  in 
the  development  of  a  specification.  All  checks,  except 
those  for  missing  cases  and  nondeterminism,  execute 
in  a  few  seconds  and  are  typically  invoked  many  times 
during  an  editing  session.  In  developing  the  CD  spec¬ 
ification,  we  frequently  used  the  less  expensive  consis¬ 
tency  checks  as  “sanity”  checks.  Since  applying  the 
more  expensive  checks  for  missing  cases  and  nondeter¬ 
minism  to  the  entire  CD  specification  usually  requires 
between  five  and  nine  minutes,  we  invoked  these  checks 
less  frequently. 


Error  Message  from  Tool 

SCR*  Highlights 

Diagnosis 

“smOperation  Mode  Transition  Table: 
Cycle  Detection  ERROR:  Cycle  #1: 

Table  smOperation  uses  mode  class 
smOperation  in  the  Name  field;  Function 
is  smOperation  Mode  Transition  Table” 

Name  of  mode 

class  in  mode 

transition  table 

Events  in  table 
for  smOperation 
introduce  a  cycle  in 
the  new  state  variable 
dependencies 

Figure  2.  Consistency  checker  feedback. 


Figure  2  gives  an  example  of  an  error  message  gen¬ 
erated  by  the  consistency  checker  during  our  develop¬ 
ment  of  the  SCR  specification  of  CD.  The  first  column 
gives  the  error  message  displayed  by  the  tool.  The  sec¬ 
ond  and  third  columns  describe  the  part  of  the  spec¬ 
ification  that  is  highlighted  at  user  request  and  our 
diagnosis  of  the  error.  In  this  example,  the  error  is 
a  circular  definition,  i.e.,  a  cycle  among  the  new  state 
dependencies.  This  cycle  occurred  on  our  first  attempt 
to  describe  CD’s  mode  transitions  in  cases  where  the 
prose  requirements  described  entry  into  a  mode  as  ulti¬ 
mately  resulting  in  exit  from  that  mode  to  some  other 
mode. 

3.3  Simulating  the  CD  Specification 

In  contrast  to  other  tools  in  SCR*,  which  are  for 
verification,  the  simulator  is  a  tool  for  validation.  The 


purpose  of  verification  is  to  prove  that  the  specifica¬ 
tion  satisfies  selected  system  properties,  such  as  state 
and  transition  invariants;  the  purpose  of  validation  is 
to  confirm  that  the  specification  captures  the  opera¬ 
tional  system  behavior  intended  by  the  customer.  The 
simulator  permits  application  experts  to  validate  the 
behavior  defined  by  the  specification  before  the  system 
is  built.  They  can  do  so  by  running  scenarios  through 
the  simulator  rather  than  by  reading  the  detailed  SCR 
specification. 

A  scenario  is  a  sequence  of  input  events,  each  of 
which  assigns  a  new  value  to  one  of  the  monitored  vari¬ 
ables.  For  each  input  event  in  the  sequence,  the  sim¬ 
ulator  updates  the  values  of  the  dependent  variables 
before  processing  the  next  input  event.  In  addition  to 
presenting  the  current  state  of  the  execution,  the  simu¬ 
lator  can  present  a  history  of  the  execution  and  report 
when  a  scenario  violates  specified  properties. 

The  simulator’s  standard  generic  interface  presents 
the  current  state  of  an  execution  in  terms  of  the  current 
values  of  the  state  variables,  i.e.,  the  monitored  vari¬ 
ables,  mode  classes,  terms,  and  controlled  variables.  A 
disadvantage  of  the  generic  interface  is  that  it  presents 
an  abstract  description  of  the  system  state  that  appli¬ 
cation  experts  find  unnatural.  To  overcome  this  prob¬ 
lem,  the  simulator  supports  the  rapid  construction  of 
graphical  front-ends  customized  for  particular  appli¬ 
cations.  Each  application-specific  front-end  contains 
graphical  representations  of  switches,  indicator  lights, 
dials,  and  other  entities  in  the  human-computer  inter¬ 
face  that,  in  contrast  to  the  generic  interface,  clearly 
and  directly  communicate  information  about  the  sys¬ 
tem  behavior  to  the  user. 

We  found  an  application-specific  front-end  for  CD 
useful  in  interacting  with  the  CD  project  manager.  Af¬ 
ter  viewing  a  simulation  of  CD  using  the  CD-specific 
front-end  (built  in  less  than  a  day),  the  CD  project 
manager  provided  us  with  useful  feedback  on  the  SCR 
specification  of  the  CD.  Thus,  evaluation  of  the  CD 
specification  through  this  front-end  to  the  simulator 
allowed  a  very  effective  use  of  a  very  scarce  commod¬ 
ity,  the  project  manager’s  time. 

3.4  Automatic  Invariant  Generation 

The  SCR*  invariant  generator  is  based  on  an  algo¬ 
rithm  for  constructing  state  invariants  from  the  func¬ 
tions  defining  the  dependent  variables.  Consider  a  de¬ 
pendent  variable  v ,  defined  by  a  mode  transition  table 
or  an  event  table,  which  takes  values  in  a  finite  set 
{oi,  02,  ■  ■  ■ ,  an}.  The  algorithm  examines  the  condi¬ 
tions  that  can  cause  the  value  of  variable  v  to  change 
and  generates  for  each  a,:  an  invariant  of  the  form 

(v  —  a  i )  -  y  CJ j . 
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where  Cj  is  a  predicate  defined  in  terms  of  variables 
on  which  v  depends.  When  v  can  take  values  in  a 
very  large  (even  infinite)  set,  the  hypotheses  v  =  a,:  are 
replaced  by  predicates  defining  a  finite  partition  on  the 
range  of  v ;  for  example,  when  v  has  a  numeric  value, 
each  predicate  will  define  an  interval.  The  appropriate 
intervals  can  often  be  computed  automatically  from 
the  specification  by  identifying  the  values  with  which 
v  is  compared. 

The  automatic  invariant  generator  currently  pro¬ 
vided  in  SCR*  partially  implements  the  algorithm 
for  generating  invariants  from  a  mode  transition  ta¬ 
ble.  The  full  algorithm,  which  we  currently  execute 
by  hand,  includes  methods  for  generating  invariants 
from  event  tables  and  condition  tables  and  a  strength¬ 
ened  method  for  mode  transition  tables;  it  will  ulti¬ 
mately  be  implemented  in  SCR*.  Figure  3  lists  the 
nontrivial  invariants  that  were  generated  automatically 
from  the  mode  transition  table  for  the  CD  mode  class 
smOperation. 


No. 

Description 

Generated  Invariant 

1 

In  Idle  mode,  the  system 
is  healthy  and  backup  power 
is  not  overvoltage 

smOperation  =  sidle 
=>  mHealthyBackground  AND 
mBackupPower  £  overvoltage 

2 

In  Standby  mode, 
backup  power  is  neither 
undervoltage  nor  unavailable 

smOperation  =  sStandby 
=>  mBackupPower  ^  undervoltage  AND 
mBackupPower  ^  unavailable 

3 

In  Traffic  Processing  mode, 
the  system  is  healthy  and 
backup  power  is  not  overvoltage 

smOperation  =  sTrafficProcessing 
=>  mHealthyBackground  AND 
mBackupPower  ^  overvoltage 

4 

In  Configuration  mode, 
the  system  is  healthy  and 
backup  power  is  not  overvoltage 

smOperation  =  sConfiguration 
=>  mHealthyBackground  AND 
mBackupPower  £  overvoltage 

Figure  3.  Nontrivial  invariants  generated  au¬ 
tomatically  for  the  mode  class  smOperation. 


Although  the  invariants  generated  from  the  specifi¬ 
cation  are  not  the  strongest  possible  invariants,  they 
are  often  sufficient  to  establish  interesting  safety  prop¬ 
erties  [18].  While  applying  the  full  invariant  genera¬ 
tion  algorithm  to  CD  did  not  provide  results  sufficient 
by  themselves  to  establish  the  security  properties  we 
wished  to  verify,  the  generated  invariants  did  play  an 
extremely  useful  role:  they  provided  every  auxiliary 
lemma  we  needed  to  complete  the  proofs  of  all  valid  se¬ 
curity  properties  that  we  investigated.  Although  there 
is  no  guarantee  that  this  will  always  happen,  that  it 
did  happen  for  CD  suggests  that  applying  invariant 
generation  is  a  useful  first  step  in  verifying  a  set  of 
properties,  particularly  since,  once  the  full  algorithm 
is  implemented  in  SCR*,  invariant  generation  will  be 
fully  automatic. 

Three  of  the  seven  properties  that  we  analyzed  could 
not  be  proven  automatically  with  either  TAME  or  the 
SCR*  validity  checker  (see  Sections  3.6  and  3.7).  To 
prove  these  properties,  a  total  of  five  auxiliary  invari¬ 


ants  were  needed.  Of  these  five  invariants,  which  are 
listed  in  Figure  4,  invariants  1A,  2A,  and  3A  can  be 
derived  from  invariants  generated  by  the  implemented 
algorithm.  For  example,  invariant  1A  is  implied  by 
invariant  4  in  Figure  3,  one  of  the  invariants  gener¬ 
ated  automatically  from  the  mode  transition  table  for 
smOperation.  Invariant  4A  follows  immediately  from 
additional  invariants  which  were  generated  by  hand  us¬ 
ing  the  strengthened  algorithm  for  mode  transition  ta¬ 
bles.  The  contrapositive  of  invariant  5A  is  generated 
by  applying  the  algorithm  by  hand  to  the  event  table 
defining  the  integer- valued  variable  cKeyBanklKeyl. 


No. 

Description 

Auxiliary  Invariant 

1A 

In  Configuration  mode,  backup 
power  is  not  overvoltage 

smOperation  =  sConfiguration 
=>  mBackupPower  ^  overvoltage 

2A 

In  Idle  mode,  backup 
power  is  not  overvoltage 

smOperation  =  sidle 
=>  mBackupPower  ^  overvoltage 

3A 

In  Traffic  Processing  mode,  backup 
power  is  not  overvoltage 

smOperation  =  sTrafficProcessing 
=>  mBackupPower  ^  overvoltage 

4A 

If  primary  power  is  unavailable, 
then  CD  is  in  Standby,  Alarm, 
or  Off  mode 

mPrimaryPower  =  unavailable 
=>  (smOperation  =  sStandby 
or  smOperation  =  sAlarm 
or  smOperation  =  sOff) 

5A 

If  CD  is  in  Off  mode, 
then  key  1  in  keybank  1  is  0 

smOperation  =  sOff 
cKeyBanklKeyl  =  0 

Figure  4.  Auxiliary  invariants  needed  for  CD. 


3.5  Model  Checking  Properties 

When,  as  in  SCR,  a  software  specification  describes 
a  finite-state  automaton,  one  can  model  check  its  prop¬ 
erties.  Model  checking  performs  an  exhaustive  search 
of  the  state  space  of  the  automaton.  If  the  num¬ 
ber  of  state  variables  is  large,  and  particularly  if — as 
is  common  in  software  specifications — the  individual 
variables  take  values  in  a  large  (even  infinite)  set,  the 
state  space  can  become  so  large  that  direct  exhaus¬ 
tive  search  of  the  entire  space  is  difficult  or  impossible. 
This  problem,  referred  to  as  the  state  explosion  prob¬ 
lem,  can  often  be  alleviated  by  abstraction. 

For  SCR*,  we  have  developed  automatable  abstrac¬ 
tion  methods  that  reduce  the  state  space  either  by 
eliminating  variables  irrelevant  to  a  property  ( variable 
restriction)  or  by  reducing  the  range  of  variable  val¬ 
ues  (variable  abstraction )  [5,  11].  When,  as  often  hap¬ 
pens,  even  abstraction  does  not  allow  the  state  space  to 
be  searched  exhaustively,  a  partial  search  of  the  state 
space  can  often  find  states  that  violate  a  specified  prop¬ 
erty.  In  addition  to  finding  property  violations,  most 
model  checkers  produce  counterexamples  in  the  form 
of  scenarios  (i.e.,  execution  sequences)  that  lead  to  the 
bad  state.  Below,  we  refer  to  counterexample  scenarios 
simply  as  counterexamples. 

Since  model  checking  is  largely  automatic,  using  a 
model  checker  to  check  the  validity  of  a  property  before 
trying  to  establish  the  property  with  a  theorem  prover 
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is  often  a  useful  screening  strategy.  If  Spin  finds  a 
violation,  it  produces  a  counterexample,  thus  saving 
the  effort  needed  to  generate  a  counterexample  from 
a  dead-end  in  a  proof.  In  checking  security  properties 
for  CD,  we  followed  this  strategy. 


No. 

Description 

Property 

1 

If  CD  is  tampered  with,  then 
key  1  in  keybank  1  is  zeroized 

@T(mTamper) 

=>  cKeyBanklKeyl'  =  0 

2 

When  the  zeroize  switch  is  activated, 
key  1  in  keybank  1  is  zeroized 

@T(mZeroizeSwitch  =  on) 

=>  cKeyBanklKeyl'  =  0 

3 

No  key  can  be  stored  in  location  1 
of  keybank  1  before  an  algorithm 
has  been  loaded  into  the  first  location 
of  algorithm  storage  segment  1 

cKeyBanklKeyl  ^  0 
=>  cAlgStoreSegmentl  ^  0 

4 

If  backup  power  has  an  undervoltage 
when  primary  power  is  unavailable, 
the  CD  enters  either  Alarm  mode  or 

Off  mode 

@T(mBackupPower  =  undervoltage) 
WHEN  mPrimaryPower  =  unavailable 
=>  smOperation'  =  sAlarm 

OR  smOperation'  =  sOff 

5 

If  backup  power  is  overvoltage 
then  the  CD  is  in  Initialization, 

Standby,  Alarm,  or  Off  mode 

mBackupPower  =  overvoltage 
=>  smOperation  =  slnitialization 

OR  smOperation  =  sStandby 

OR  smOperation  =  sAlarm 

OR  smOperation  =  sOff 

6 

If  primary  power  has  an  overvoltage 
then  either  the  CD  is  in  Initialization, 
Standby,  Alarm,  or  Off  mode,  or  the  CD 
enters  Initialization  mode 

@T(mPrimary  Power)  =  overvoltage 
=>  smOperation  =  sStandby 

OR  smOperation  =  sAlarm 

OR  smOperation  =  sOff 

OR  smOperation'  =  slnitialization 

7 

If  primary  power  has  an  undervoltage 
then  either  the  CD  is  in  Initialization, 
Standby,  Alarm,  or  Off  mode,  or  the  CD 
enters  Initialization  mode 

@T(mPrimary  Power)  =  undervoltage 
=>  smOperation  =  sStandby 

OR  smOperation  =  sAlarm 

OR  smOperation  =  sOff 

OR  smOperation'  =  slnitialization 

Figure  5.  Sample  true  properties  for  SCR  CD. 


Figure  5  lists  seven  security  properties  that  the 
SCR  specification  of  CD  satisfies.  Before  we  tried 
to  prove  any  CD  security  property  with  TAME  (see 
Section  3.6),  we  first  used  the  Spin  model  checker  to 
search  for  violations  of  the  property.  For  each  property, 
we  used  SCR*  to  automatically  extract  an  abstrac¬ 
tion  from  the  CD  specification  and  the  property,  us¬ 
ing  the  variable  restriction  method  described  in  [5,  11] 
to  remove  all  variables  irrelevant  to  the  validity  of  the 
property.  Then,  by  hand,  we  applied  the  variable  ab¬ 
straction  method  described  in  [11],  By  limiting  the 
range  of  values  that  certain  variables  can  assume,  this 
method  usually  produces  a  smaller  abstraction.  In  our 
CD  study,  the  abstractions  for  different  properties  var¬ 
ied  very  little.  A  typical  abstraction  contained  28  vari¬ 
ables,  a  reduction  of  28%  from  the  39  variables  in  the 
complete  SCR  specification. 

Using  Spin,  we  discovered  a  few  property  violations. 
In  each  case,  closer  examination  of  the  property  showed 
that  the  formulation  of  the  property  was  incorrect.  As 
one  would  expect,  model  checking  was  unable  to  find 
any  violations  of  the  properties  subsequently  verified 
by  theorem  proving.  Because  the  model  checker  ran 
out  of  memory  before  the  analysis  was  complete,  we 
were  unable  to  search  the  complete  state  space  of  any  of 
the  abstract  specifications  and  therefore  to  verify  any 
of  the  properties  listed  in  Figure  5.  The  importance 


of  the  theorem  proving  phase  was  demonstrated  when 
we  were  able  to  use  theorem  proving  both  to  prove 
that  certain  properties  were  invariants  and  to  establish 
that  one  property  for  which  Spin  was  unable  to  find  a 
violation  is  not  an  invariant  (see  below). 

3.6  Checking  Properties  with  TAME 

The  tool  TAME  provides  an  interface  to  PVS  for 
proving  properties  of  automata  models.  TAME’s  goal 
is  to  reduce  the  human  effort  required  in  using  PVS 
to  specify  these  automata  models  and  to  prove  state 
invariant  properties  for  the  models.  TAME  was  orig¬ 
inally  designed  to  specify  and  reason  about  Lynch- 
Vaandrager  (LV)  timed  automata  [21]  but  has  been 
adapted  to  I/O  automata  [20]  and  the  automata  model 
underlying  SCR  (see  [2]).  TAME  provides  more  than 
twenty  specialized  strategies  that  implement  proof 
steps  mimicking  the  high-level  proof  steps  typically 
used  by  humans  in  proving  invariant  properties.  Ex¬ 
perience  has  shown  that  for  automata  models  whose 
state  variables  have  simple  types  (such  as  numerical, 
boolean,  or  enumerated  types),  nearly  all  state  invari¬ 
ants  can  be  proved  using  the  TAME  steps  exclusively. 

We  have  integrated  TAME  into  SCR*  by  develop¬ 
ing  an  automatic  SCR-to-TAME  translator  and  special 
TAME  strategies  for  the  automatic  analysis  of  proper¬ 
ties  of  SCR  automata  [2].  For  many  SCR  automata, — 
in  particular,  those  not  involving  timing  constraints 
or  other  complexities  such  as  tolerances  for  controlled 
quantities — a  single  TAME  strategy  can  automatically 
prove  many  state  invariants. 

As  stated  in  Section  2,  most  invariant  properties 
of  interest  for  an  SCR  automaton  are  either  state  in¬ 
variants  (one-state  properties)  or  transition  invariants 
(two-state  properties).  State  invariants  are  typically 
proved  by  induction,  with  a  base  case  for  the  initial 
states  and  an  action  case  for  each  kind  of  input  event. 
Although  induction  can  be  used  in  proving  transition 
invariants,  it  is  seldom  appropriate,  since  the  transi¬ 
tions  possible  from  any  given  state  seldom  have  any 
connection  to  the  transitions  possible  from  one  of  its 
successor  states.  Rather,  transition  invariants  are  nor¬ 
mally  proved  by  reasoning  directly  about  the  transition 
relation  of  the  SCR  automaton. 

In  TAME,  the  strategy  SCR.INDUCT_PROOF  per¬ 
forms  the  standard  parts  of  an  induction  proof  for  a 
state  invariant,  and  SCR_DIRECT_PROOF  does  the 
same  for  a  transition  invariant.  A  universal  invari¬ 
ant  proof  strategy  identifies  the  invariant  as  either  a 
one-state  or  two-state  property  and  then  applies  either 
SCR  JNDUCT.P  ROOF  or  SCR_DIRECT.PROOF  as 
appropriate. 

Properties  1,  2,  and  3  in  Figure  5  took  a  few  days 
to  prove  because  the  initial  TAME  representation  of 
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CD  combined  with  the  initial  versions  of  the  strategies 
SCRJNDUCT.PROOF  and  SCR_DIRECT_PROOF 
led  to  unmanageably  large  data  structures  in  the  PVS 
prover.  These  problems  led  us  to  improve  both  our 
translation  scheme  and  our  proof  strategies.  After 
these  improvements  were  made,  we  were  able  to  prove 
properties  5,  6,  and  7  in  Figure  5  in  less  than  an  hour. 
The  proof  of  property  4  took  longer — about  2  days — 
because  we  needed  to  discover  and  to  prove  two  lay¬ 
ers  of  auxiliary  invariants.  This  time  would  have  been 
greatly  reduced  if  the  full  invariant  generation  algo¬ 
rithm  (see  Section  3.4)  had  been  automated. 

When  TAME’s  universal  invariant  strategy  fails  to 
complete  the  proof  of  an  invariant,  two  possibilities 
exist:  either  the  invariant  is  false,  or  additional  invari¬ 
ants  are  needed  in  the  proof.  Associated  with  every 
proof  “dead-end”  is  a  problem  transition.  For  one- 
state  properties,  this  is  the  transition  of  the  action  case 
in  the  induction  proof  in  which  the  dead-end  appears. 
For  two-state  properties,  this  is  the  transition  from  the 
given  state  via  some  enabled  automaton  action  to  the 
successor  state;  the  strategy  SCR_DIRECT_PROOF 
produces  only  dead-ends  in  which  the  action  is  known, 
and  hence  for  deterministic  SCR  specifications,  the 
successor  state  (in  terms  of  the  given  state)  is  known. 
TAME  provides  an  analysis  strategy  to  display  the  de¬ 
tails  of  any  problem  transition.  Once  these  details  are 
understood,  the  user  can  determine  whether  the  transi¬ 
tion  is  reachable — in  which  case,  the  property  is  false — 
or  whether  it  is  unreachable,  either  because  it  would 
violate  some  transition  invariant,  or  because  one  or  the 
other  of  the  states  in  the  transition  violates  some  state 
invariant. 

Applying  abstraction  to  a  specification  is  less  impor¬ 
tant  in  theorem  proving  than  in  model  checking.  Since 
a  theorem  prover  can  reason  about  abstract  values,  re¬ 
ducing  the  range  of  a  variable  using  variable  abstrac¬ 
tion  results  in  little  or  no  improvement  in  the  num¬ 
ber  of  cases  the  theorem  prover  must  consider.  How¬ 
ever,  variable  restriction  can  reduce  both  the  number  of 
cases  and  the  complexity  of  reasoning  about  state  tran¬ 
sitions.  Therefore,  prior  to  analyzing  a  property  with 
TAME,  we  applied  variable  restriction  to  the  specifi¬ 
cation.  Because  the  resulting  abstractions  for  the  indi¬ 
vidual  properties  were  very  similar,  we  used  the  same 
abstraction  for  all. 

Applying  the  TAME  strategies  to  the  seven  prop¬ 
erties  in  Figure  5  resulted  in  the  automatic  proof  of 
four  of  the  properties.  For  two  of  the  remaining  prop¬ 
erties,  we  proposed  an  auxiliary  invariant,  which  was 
proved  automatically  and  then  applied  to  complete 
the  proof.  Property  1  in  Figure  5  is  an  example  of  a 
property  requiring  a  single  auxiliary  invariant,  invari¬ 


ant  5A  in  Figure  4,  in  its  proof.  Examination  of  the 
event  table  for  the  variable  cKeyBanklKeyl,  in  Fig¬ 
ure  6  shows  why  the  auxiliary  invariant  is  needed:1 
when  CD  is  in  mode  sOff ,  the  event  OT(mTamper)  does 
not  change  the  value  of  cKeyBanklKeyl.  Invariant  5 A, 
which  states  that  cKeyBanklKeyl  is  0  in  mode  sOff, 
clearly  covers  this  case. 


Figure  6.  Event  table  for  cKeyBanklKeyl 


In  the  case  of  the  third  remaining  property,  we  sug¬ 
gested  an  auxiliary  invariant  that  completed  the  proof. 
However,  applying  the  automatic  proof  strategy  to  the 
auxiliary  invariant  resulted  in  several  dead-ends,  and 
we  therefore  proposed  three  additional  auxiliary  invari¬ 
ants.  These  three  new  invariants  were  then  proved  au¬ 
tomatically  using  the  universal  invariant  strategy.  As 
noted  in  Section  3.4,  each  of  the  needed  auxiliary  in¬ 
variants  was  subsumed  or  implied  by  invariants  that  ei¬ 
ther  were,  or  could  be,  generated  automatically.  Thus, 
once  the  invariant  generator  is  extended  and  commu¬ 
nication  between  the  invariant  generator  and  TAME 
is  possible,  the  class  of  invariants  that  can  be  proved 
automatically  using  TAME  will  be  extended. 

Figure  7  shows  a  proposed  eighth  property  that 
does  not  hold  in  the  CD  specification.  Although  Spin 


Description 

Property 

If  CD  is  in  Alarm  mode,  then 
key  1  in  keybank  1  is  0 

smOperation  =  sAlarm 
=>  cKeyBanklKeyl  =  0 

Figure  7.  A  false  property  for  SCR  CD. 

'Some  of  the  conditions  and  events  have  been  abbreviated 
using  ellipsis. 
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was  unable  to  produce  a  counterexample  for  this  prop¬ 
erty,  TAME’s  analysis  of  the  property  found  14  prob¬ 
lem  transitions.  Some  intelligent  exploration  using  the 
SCR*  simulator  produced  a  scenario  that  leads  to  one 
of  these  transitions,  thus  demonstrating  that  the  prop¬ 
erty  does  not  hold  in  the  SCR  specification.  Detailed 
examination  of  the  feedback  from  TAME  shows  that 
no  obvious  invariants  forbid  the  other  problem  transi¬ 
tions,  so  it  is  likely  that  they  also  correspond  to  coun¬ 
terexamples. 

3.7  Applying  the  Validity  Checker 

The  SCR*  validity  checker  VC  [4]  checks  the  valid¬ 
ity  of  first-order  one-state  or  two-state  properties  di¬ 
rectly  by  using  an  initial  term-rewriting  phase  followed 
by  application  of  a  decision  procedure  that  uses  BDDs 
(binary  decision  diagrams)  to  evaluate  propositional 
formulae  and  a  constraint  solver  to  reduce  simple  in¬ 
teger  arithmetic  formulae  (Presburger  formulae).  The 
variable  ordering  used  in  the  BDDs  is  particularly  ef¬ 
ficient  for  SCR  specifications.  VC  can  also  perform 
an  induction  proof  of  a  property  by  first  applying  a 
preprocessor  to  generate  the  appropriate  base  and  in¬ 
duction  cases  and  then  applying  the  direct  method  to 
the  generated  cases.  An  automatic  translation  of  SCR 
specifications  into  input  for  VC  has  been  built. 

VC  has  been  applied  to  many  of  the  same  exam¬ 
ples  to  which  TAME  has  been  applied,  including  the 
CD  properties  (after  abstraction,  as  with  TAME).  The 
run  time  required  by  VC  to  analyze  the  CD  properties 
was  about  half  the  time  required  by  TAME.  For  the 
false  property  in  Figure  7,  VC  produced  a  single  prob¬ 
lem  transition,  a  special  case  of  one  of  the  14  problem 
transitions  reported  by  TAME.  This  is  the  same  prob¬ 
lem  transition  for  which  we  used  the  simulator  to  find 
a  counterexample.  Thus,  VC,  like  TAME,  can  be  used 
in  demonstrating  that  a  property  is  invalid. 

Unlike  TAME,  VC  cannot  be  used  to  prove  proper¬ 
ties  interactively.  Therefore,  the  CD  properties  whose 
proofs  required  auxiliary  invariants  were  checked  af¬ 
ter  first  including  all  necessary  auxiliary  invariants 
as  assumptions,  rather  than  by  interactively  invok¬ 
ing  an  analog  of  TAME’s  strategy  for  applying  an  in¬ 
variant  lemma.  Mechanically  checking  the  validity  of 
complex  properties  (such  as  properties  involving  non¬ 
linear  numerical  constraints  or  numerical  constraints 
over  real  numbers,  or  properties  whose  proofs  require 
types  of  higher-order  reasoning  other  than  induction 
over  reachable  states)  requires  a  general-purpose  theo¬ 
rem  prover,  such  as  PVS  through  TAME.  However,  VC 
can  provide  an  efficient  first  screening  for  invariance 
for  any  property  of  an  automaton  that  involves  only 
propositional  logic,  simple  integer  constraints,  and  uni¬ 
versal  quantification  over  states  or  state  pairs. 


3.8  Generating  Test  Sets 

Applying  the  formal  techniques  described  above 
produces  very  high-quality  requirements  specifications. 
Although  such  high-quality  requirements  specifica¬ 
tions  are  valuable,  the  ultimate  objective  of  the  soft¬ 
ware  development  process  is  to  produce  high-quality 
software — software  that  satisfies  its  requirements.  To 
weed  out  errors  introduced  by  the  implementation  and 
to  convince  customers  that  the  system  performance  is 
acceptable,  the  software  needs  to  be  tested.  An  enor¬ 
mous  problem,  however,  is  that  software  testing,  espe¬ 
cially  of  secure  systems,  is  extremely  costly  and  time- 
consuming.  It  has  been  estimated  that  current  testing 
methods  consume  between  40%  and  70%  of  the  soft¬ 
ware  development  effort  [3]. 

The  high-quality  specification  produced  by  the  SCR 
method  can  play  a  valuable  role  in  software  testing.  We 
have  developed  an  automated  technique  [9]  that  con¬ 
structs  a  suite  of  test  sets  from  an  SCR  requirements 
specification.  Each  test  set  is  a  sequence  of  system  in¬ 
puts  in  which  each  input  is  coupled  with  the  required 
system  outputs.  To  ensure  that  the  test  sets  “cover” 
the  set  of  all  possible  system  behaviors,  our  technique 
organizes  all  possible  system  executions  (i.e.,  traces) 
into  equivalence  classes  and  builds  one  or  more  test 
sets  for  each  class.  These  test  sets  can  then  be  used 
to  automatically  evaluate  the  implemented  software. 
By  reducing  the  human  effort  needed  to  build  and  to 
run  the  test  sets,  such  an  approach  can  reduce  both 
the  enormous  cost  and  the  significant  time  and  human 
effort  associated  with  current  testing  methods. 

With  our  technique,  a  model  checker’s  ability  to  pro¬ 
duce  counterexamples  is  used  to  construct  the  test  sets. 
The  requirements  specification  is  used  both  to  gener¬ 
ate  a  valid  sequence  of  inputs  and  as  an  oracle  that 
determines  the  outputs  the  system  is  required  to  gen¬ 
erate  from  a  given  system  input.  To  obtain  a  valid 
sequence  of  inputs,  the  input  sequence  is  constrained 
to  satisfy  the  environmental  assumptions  in  the  SCR 
requirements  specification. 

We  have  built  a  prototype  tool  in  Java  that  auto¬ 
matically  translates  an  SCR  specification  into  the  lan¬ 
guage  of  either  of  two  model  checkers,  executes  the 
model  checker  to  build  the  test  sets,  analyzes  its  out¬ 
puts,  and  finally  produces  a  file  containing  the  gener¬ 
ated  test  sets.  Our  prototype  tool  has  been  applied 
to  a  number  of  specifications,  including  a  sizable  com¬ 
ponent  of  a  contractor-specified  weapons  system  [11]. 
Given  the  tool’s  early  success  in  constructing  test  sets 
efficiently,  we  expect  that  applying  the  tool  to  the  CD 
specification  should  be  equally  successful.  The  CD 
project  manager  has  expressed  interest  in  using  test 
sets  generated  by  our  tool  to  test  the  CD  software. 


4  Discussion 

The  Complexity  of  CD.  Our  SCR  specification  of 
CD  reflects  the  application’s  significant  complexity  and 
moderate  size.  As  noted  in  Section  3.1,  the  SCR  spec¬ 
ification  has  39  variables,  and  the  relationships  among 
these  variables  is  complex.  In  any  state  after  the  ini¬ 
tial  state,  the  monitored  variable  mHostCommand  can 
take  one  of  17  values,  and  therefore,  in  any  state  of 
the  CD,  there  are  16  possible  input  events  involving 
changes  in  this  variable.  In  addition,  there  are  17  other 
input  variables.  As  a  result,  the  mode  transition  table 
is  large,  involving  55  events  to  define  25  mode  transi¬ 
tions,  and  many  event  tables  in  the  specification  are 
also  large:  the  average  number  of  events  per  table  is  8, 
with  the  largest  table  containing  16  events. 

Time  and  effort  required.  Despite  the  complexity 
of  CD,  the  total  time  taken  in  this  study  to  develop 
and  analyze  the  SCR  CD  specification  was  only  one 
person-month.2  Formalizing  the  specification  of  CD 
in  SCR,  including  the  use  of  the  analysis  tools  to  per¬ 
form  sanity  checks,  took  only  two  person-weeks,  and 
even  the  most  complex  consistency  checks  ran  in  min¬ 
utes.  The  graphical  front-end  for  simulation  of  CD  was 
constructed  in  one  day.  Improvements  to  formulation 
of  the  properties  based  on  feedback  from  the  model 
checker  took  only  a  few  days.  TAME  and  the  validity 
checker  underwent  significant  improvement  during  our 
analysis  of  the  SCR  specification  of  CD,  and  as  a  re¬ 
sult,  analyzing  a  property  with  these  tools  now  takes 
at  most  a  few  minutes,  and  sometimes  only  a  few  sec¬ 
onds.  The  most  labor-intensive  part  of  the  analysis 
of  a  property  is  analyzing  proof  dead-ends  to  deter¬ 
mine  their  cause  and  their  resolution.  As  noted  above, 
we  plan  to  fully  implement  the  invariant  generation 
algorithm.  This  extension  of  SCR*  should  reduce  sig¬ 
nificantly  the  problem  of  discovering  useful  auxiliary 
invariants. 

The  practicality  of  SCR.  For  our  SCR  specification 
of  CD,  we  analyzed  eight  security  properties.  For  each 
property,  we  were  able  to  definitively  answer  the  ques¬ 
tion,  “Does  the  operational  specification  satisfy  this 
property?”  When  the  answer  was  “No,”  we  provided  a 
counterexample  illustrating  the  failure.  Although  the 
full  set  of  security  properties  for  CD  (to  which  we  do 
not  have  access)  numbers  in  the  hundreds,  our  success 
with  the  properties  we  considered  and  the  relatively 
short  time  required  support  the  proposition  that  SCR 
and  the  analysis  techniques  supported  in  SCR*  pro¬ 
vide  a  practical,  low-cost  approach  to  providing  high 
assurance.  Typical  concerns  expressed  by  practitioners 

Additional  time  was  needed  to  make  improvements  in  some 
of  the  SCR*  techniques.  These  improvements  were  suggested  by 
our  experience  with  CD. 


regarding  the  practicality  of  formal  methods  are  ad¬ 
dressed  in  more  detail  in  our  discussion  in  [17]  of  the 
lessons  we  learned  from  our  application  of  the  SCR* 
tools  to  CD. 

5  Related  Work 

RSML  (Requirements  State  Machine  Language)  [10] 
is  another  requirements  method  in  which,  as  in  SCR, 
a  system  is  specified  as  a  state  machine.  RSML  has 
been  successfully  applied  to  finding  errors  in  the  speci¬ 
fication  of  a  complex  avionics  system:  the  Traffic  alert 
and  Collision  Avoidance  System  II  (TCAS  II).  Like 
SCR  specifications,  RSML  specifications  include  a  set 
of  tables  and  may  be  checked  for  consistency  and  for 
(a  version  of)  completeness.  SCR  and  RSML  also  have 
important  differences.  First,  RSML  has  a  Statecharts- 
style  interface  through  which  it  explicitly  supports 
specification  features,  such  as  hierarchical  states  and 
local  variables,  not  explicitly  supported  in  SCR  (al¬ 
though  similar  effects  can  be  obtained  with  SCR).  Fur¬ 
ther,  the  AND/OR  tables  in  RSML  specify  details  of 
transitions ,  while  SCR  tables  specify  how  dependent 
state  variables  are  updated.  Because  a  state  machine 
has  many  more  transitions  than  state  variables,  an 
RSML  specification  of  a  system  contains  many  more 
tables  than  an  SCR  specification  of  the  same  system. 
Finally,  automated  support  for  the  analysis  of  RSML 
specification  properties  beyond  consistency  and  com¬ 
pleteness  is  not  yet  extensive. 

Reference  [24]  describes  an  earlier  application  of 
SCR  to  the  development  of  another  COMSEC  device, 
the  External  COMSEC  Adaptor  (EC A).  The  develop¬ 
ment,  from  modeling  the  device  through  implement¬ 
ing  and  verifying  its  design,  was  done  using  the  high- 
level  SCR  method,  but  not  the  SCR*  toolset.  The 
operational  requirements  were  specified  using  SCR  ta¬ 
bles,  and  the  critical  requirements  model — the  desired 
properties — was  specified  using  the  CSP  (Communi¬ 
cating  Sequential  Processes)  language.  In  this  effort, 
both  formal  and  informal  transitions  between  stages 
were  used,  with  some  automated  support  for  the  formal 
transitions  from  another  mechanized  theorem  prover. 

6  Conclusion 

SCR  offers  a  practical,  low-cost  approach  to  build¬ 
ing  a  high  assurance  COMSEC  device.  Before  imple¬ 
mentation  and  design,  the  SCR*  toolset  can  be  used 
to  build  and  analyze,  often  automatically,  a  mathe¬ 
matically  precise  requirements  specification.  Opera¬ 
tional  personnel  can  use  the  SCR*  simulator  to  val¬ 
idate  the  behavior  of  the  specified  system.  Further, 
model  checking  often  can  be  used  to  identify  security 
properties  which  the  operational  specification  violates, 
and  theorem  proving  can  be  used  to  verify  the  correct- 
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ness  of  security  properties  and  suggest  possible  prop¬ 
erty  violations.  When  analyses  have  established  suffi¬ 
cient  confidence  in  the  requirements  specification,  the 
system  can  be  built  to  satisfy  that  specification.  A 
planned  extension  to  SCR*,  a  tool  to  generate  Java 
code  from  specifications,  will  help  with  this  phase  of 
development.  Once  the  source  code  is  available,  test 
sets  automatically  generated  from  the  operational  re¬ 
quirements  specification  by  the  test  set  generator  can 
be  used  to  test  the  system  implementation. 
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